Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make company configurable as far as possible #8

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

jokram
Copy link

@jokram jokram commented Jan 17, 2017

Tried to make the code independent from Autodesk. So it should only depend on enterprice.constants.

  • Replaced "adsk" with "$KIT_ID" where possible
  • Replaced "Autodesk" with "GitHub Enterprise"
  • Replaced "ADS_USER" with "GHE_USER"
  • Replaced "ADS_PASSWORD_OR_TOKEN" with "GHE_PASSWORD_OR_TOKEN"

Exceptions:

  • config.include: Here I've not yet found a way to make this dependent on enterprise.constants
  • Readme.md: For another company the Readme should be adapted, because it is delivered to end users

Important Notes:

  • I've had a merge conflict on my test branch where I've already included feature/configurable-protocol
    So I've merged feature/configurable-protocol into this branch. Best is if you first check the other pull request Add GITHUB_PROTOCOL support (http or https) #7
  • I'm not yet able to test these changes, because there are other changes necessary before I can run it in my company environment:
    • JIRA link is different
    • Conventions for service account is different
    • Currently we are using SSH
    • Installation of LFS might fail due to proxy authentification
  • But I want to address these issues with separate pull requests

else
echo -n "Please enter your Autodesk username and press [ENTER] (empty for \"$STORED_GITHUB_ENTERPRISE_ACCOUNT\"): "
echo -n "Please enter your GitHub Enterprise username and press [ENTER] (empty for \"$STORED_GITHUB_ENTERPRISE_ACCOUNT\"): "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of our engineers confuse GitHub Enterprise with github.com. Therefore I used the company name here. Maybe we should make this an enterprise.config setting?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree.

git --git-dir="$KIT_PATH/.git" --work-tree="$KIT_PATH" checkout --quiet -B adsk-setup && \
# [jokram] Why is the checkout of a new branch adsk-setup necessary? The reset --hard will overwrite it, or?
# Or is it just to mark that this was the previous version?
git --git-dir="$KIT_PATH/.git" --work-tree="$KIT_PATH" checkout --quiet -B $KIT_ID-setup && \
git --git-dir="$KIT_PATH/.git" --work-tree="$KIT_PATH" reset --quiet --hard origin/$BRANCH && \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The checkout is necessary to make sure we are on the "adsk-setup" branch. If you develop enterprise-config then you might be on branch X. If you run it then it would hard reset X to the latest production state and you would "lose" your changes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think now I got it:
git reset --hard origin/production will modify the current branch pointer (which might be branch-X) to also point to origin/production. And by this the branch-X would have been modified. So git checkout -B adsk-setup is just to ensure that you have temp. branch which can be modified by the reset command.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But why not just: git checkout -B adsk-setup origin/production?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That call can fail if you have local uncommitted changes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Next try: git checkout -f -B adsk-setup origin/production
Documentation for -f says:

When switching branches, proceed even if the index or the working tree differs from HEAD. This is used to throw away local changes.

@@ -9,6 +9,10 @@ KIT_ID='adsk'
# Define your GitHub Enterprise server
GITHUB_SERVER='git.yourcompany.com'


# Add the protocol used to access GitHub server: http or https
GITHUB_PROTOCOL='https'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should follow your naming convention from GHE_USER etc. here and call this GHE_HTTP?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plus, I would vote against using the term PROTOCOL because that could also mean "SSH"...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then maybe also for GITHUB_SERVER => GHE_SERVER

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

KIT_PATH=$(dirname "$0")
. "$KIT_PATH/../enterprise.constants"

PROTOCOL=$GITHUB_PROTOCOL
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you define PROTOCOL here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would not be necessary, but I was thinking that the helpers normaly are independent from GitHub, so I wanted to avoid to mention in the helper functions no GITHUB_* variable.
What would you prefer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this approach if it is a local variable in a function. But here PROTOCOL as well as GITHUB_PROTOCOL are global variables and therefore I would prefer to only use the latter.

@larsxschneider
Copy link
Contributor

@jokram : I haven't forgotten this PR. I am just super busy right now. This looks pretty good - I'll merge it ASAP. Are you blocked in any way?

@jokram
Copy link
Author

jokram commented Jan 24, 2017

@larsxschneider: No problem. I'm still analyzing.
Note: After merging the master branch further fixes are necessary before mering the pull request.
I'll let you know when it make sense to review the changes (I need to push new commits with some fixes).

@larsxschneider
Copy link
Contributor

OK. Sounds good! Don't hesitate to reach out to me if you run into any trouble with the enterprise-config-for-git setup.

@jokram
Copy link
Author

jokram commented Jan 24, 2017

Concerning the proxy you might be right. But this will take a bit longer to understand, but it might be worth to avoid problems in the field.

I've created a DESIGN.md file to write down my analysis results. In addition this contains some design ideas you might have a look at (if the stress is decreasing a bit). But these ideas should be discussed first before continuing. Maybe it makes sense to cover this in a separate pull request or issue.

ballab1 pushed a commit to ballab1/enterprise-config-for-git that referenced this pull request Nov 24, 2019
Require latest Git and Git LFS versions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants