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

Update branching option to branch from another branch. #4531

Merged
merged 3 commits into from
Jun 29, 2017

Conversation

adbridge
Copy link
Contributor

@adbridge adbridge commented Jun 12, 2017

Previously if updating a branch in the ARMmbed version of an example
repo, the branch would be created initially from master. This update
allows the new branch to be created from any pre-existing branch.
This update also moves the branch / fork / tag configuration data to the
json config file. It thus simplifies the command line.
-b on its own now indicates use the branch information in the config
-f on its own now indicates use the fork information in the config

Previously if updating a branch in the ARMmbed version of an example
repo, the branch would be created initially from master. This update
allows the new branch to be created by any pre-existing branch.
This update also moves the branch / fork / tag configuration data to the
json config file. It thus simplifies the command line.
-b on its own now indicates use the branch information in the config
-f on its own now indicates use the fork information in the config
@theotherjimmy
Copy link
Contributor

lol. love the title

Copy link
Contributor

@theotherjimmy theotherjimmy left a comment

Choose a reason for hiding this comment

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

Looks fine. Nits, questions and future work below.


# Push new branch upstream
cmd = ['git', 'push', '-u', 'origin', dst]
return_code = run_cmd(cmd)
Copy link
Contributor

Choose a reason for hiding this comment

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

If all of these commands share error behavior, could we have a construct like:

for cmd in [['git', 'checkout', src],
            ['git', 'checkout', '-b', dst],
            ['git', 'push', '-u', 'origin', dst]]:
    return_code = run_cmd(cmd)
    if return_code:
        break
else:
    update_log.error("Failed to prepare branch: %s", dst)

Copy link
Contributor Author

@adbridge adbridge Jun 13, 2017

Choose a reason for hiding this comment

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

Not sure that does what you think? If each command ran successfully then there would be no break , the loop would terminate and the 'else' clause run...
From python help:
"For loops also have an else clause which most of us are unfamiliar with. The else clause executes when the loop completes normally. This means that the loop did not encounter any break. ". Could be tweaked to replace the 'else' clause with an additional check of return_code though

Copy link
Contributor

Choose a reason for hiding this comment

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

Eh, fine use if return_code.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, I was thinking of:

for cmd in [['git', 'checkout', src],
            ['git', 'checkout', '-b', dst],
            ['git', 'push', '-u', 'origin', dst]]:
    return_code = run_cmd(cmd)
    if return_code:
        break
else:
    return True
update_log.error("Failed to prepare branch: %s", dst)
return False

Copy link
Contributor

@theotherjimmy theotherjimmy Jun 13, 2017

Choose a reason for hiding this comment

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

OH, we can do better:

for cmd in [['git', 'checkout', src],
            ['git', 'checkout', '-b', dst],
            ['git', 'push', '-u', 'origin', dst]]:
    if run_cmd(cmd):
        update_log.error("Failed to prepare branch: %s", dst)
        return False
return True

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Have improved it further, this function doesn't really need to have it's own separate error so can actually just use run_cmd(cmd, exit_on_failure=True). It wasn't even checking the return from prepare_fork() or prepare_branch() anyway!

Copy link
Contributor

Choose a reason for hiding this comment

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

Nice! so:

for cmd in [['git', 'checkout', src],
            ['git', 'checkout', '-b', dst],
            ['git', 'push', '-u', 'origin', dst]]:
    run_cmd(cmd, exit_on_failure=True)


body = "Please test this PR.\n"
body += "If successful then merge, otherwise provide a known issue.\n"
body += "Once you get notification of the release being made public then tag Master with " + tag
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we make a note to replace all of these bodies with jinja templates? I think it would ease maintenance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Might be overkill for just the one case in this file ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you really think this is going to be the only case where we emit a blob of text? I think there may be more when we extend this script later.

exclusive.add_argument('-U', '--github_user', help="GitHub user for forked repos, mutually exclusive to branch option")
exclusive.add_argument('-b', '--branch', help="Branch to be updated, mutually exclusive to user option")
exclusive.add_argument('-f', '--fork', help="Update a fork", action='store_true')
exclusive.add_argument('-b', '--branch', help="Update a branch", action='store_true')
Copy link
Contributor

Choose a reason for hiding this comment

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

We could also do sumcommands here. Invocation would be python update.py fork vs python update.py -f

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure i see what the benefit here is ?

Copy link
Contributor

Choose a reason for hiding this comment

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

in unix tradition, things starting with "-" are flags that are optional. before you use make.py, bulid.py or project.py as an example, remember that I did not write that bit, and it can't be changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

mmm but by that argument you would have something like :
update.py token 12eedf34455gggg
Which doesn't feel right to me at all -T 12eedf34455gggg is much more intuitive, but it is still a compulsory argument.. ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not quite. Do you need the github token to work correctly? Could you do a "dry run" without it?

Copy link
Contributor

Choose a reason for hiding this comment

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

@adbridge For things that are booleans/enums, you end up with subcommands, for things that are required and not booleans/enums, you end up with positional arguments. That's the unix tradition that I'm familiar with

Copy link
Contributor Author

@adbridge adbridge Jun 14, 2017

Choose a reason for hiding this comment

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

You also need the tag in there :)
I could live with having 'branch' or 'fork' as mutually exclusive sub-commands , think the others will stay as they are.

Copy link
Contributor

Choose a reason for hiding this comment

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

@adbridge This is really a style issue, so it comes down to your preference. I think that you will likely be the most common user of this script.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Eventually the CI will be the user , but it would ultimately be nice to have a consistent approach across all our tools ...

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, computers aren't really the consumers. I'm expecting that you will write the script or job that calls this script in CI. That would make you the consumer.

@adbridge
Copy link
Contributor Author

@theotherjimmy ok I think that's the last of the comments, can you just double check the last couple of commits? Thanks

@@ -475,13 +481,15 @@ def create_work_directory(path):
failures = []
successes = []
results = {}
template = dirname(abspath(__file__))
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is the template. Maybe it's the template directory?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah template directory, seemed like too long a name though ! Could have gone with tmpl_dir or similar I guess .

Copy link
Contributor

Choose a reason for hiding this comment

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

¯\_(ツ)_/¯

Copy link
Contributor

@theotherjimmy theotherjimmy left a comment

Choose a reason for hiding this comment

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

Looks great!

@theotherjimmy
Copy link
Contributor

@adbridge Does this need to be run through CI?

@adbridge
Copy link
Contributor Author

adbridge commented Jun 27, 2017

@theotherjimmy We can run through ci if we want but this script doesn't get tested by anything there...

@theotherjimmy
Copy link
Contributor

Cool. Let's merge when Cam-CI gets back to us.

@0xc0170
Copy link
Contributor

0xc0170 commented Jun 28, 2017

retest uvisor

@theotherjimmy theotherjimmy merged commit 18b1cb6 into ARMmbed:master Jun 29, 2017
@adbridge
Copy link
Contributor Author

adbridge commented Jul 5, 2017

@theotherjimmy This was merged without a release label! Should really have gone to 5.5.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants