contentPadding: EdgeInsets.zero,
Stackoverflow
https://stackoverflow.com/questions/50905591/flutter-how-to-remove-white-spaces-around-dialog-box
View Full Article Here
2 Encoding the KeyStore
The next step treats the encoding of the KeyStore file. At this point, I assume you already own your KeyStore file. If you don’t have experience with app-signing, I suggest you take a look at the already mentioned documentation.
For encoding, we will make use of the popular Base64 encoding scheme. Base64 doesn’t stand for specific but various encoding schemes that allow you to convert binary data into a text representation.
In our case, the encoding of the KeyStorefile will allow us to store the file as text in our GitHub Secrets and later on in the GitHub Workflow process decode it back to our original KeyStore file.
The encryption step can easily be done by using OpenSSL. Download and install it, then navigate to the folder that contains your .jks file. Within the respective folder, execute the following command in your Unix terminal or just use Git bash on Windows:
openssl base64 < your_signing_keystore.jks | tr -d '\n' | tee your_signing_keystore_base64_encoded.txt
If everything went right, you should see a newly created file your_signing_keystore_base64_encoded.txt which contains a cryptic text that represents your KeyStore file.
3 The GitHub Actions Workflow
To build our CI/CD pipeline, we will use GitHub Actions. But before we can start implementing our Workflow, we first need to set up our GitHub secrets.
3.1 Set up your GitHub Secrets
In the following section, I assume that you used the identifiers from the mentioned build.gradle file. If you renamed the environment variables, you need to adapt the GitHub Secret names accordingly.
The first secret we will add is the encoded Base64 representation of our KeyStore file. To do so, go into your project’s GitHub secrets and add a new GitHub Secret called KEYSTORE.
Copy the content from the your_signing_keystore_base64_encoded.txt file and paste it into the value field.
Next, create a secret that is called SIGNING_STORE_PASSWORD and contains your KeyStore password.
Afterward, create one that is called SIGNING_KEY_PASSWORD and contains your key alias password.
The last secret we need to add is called SIGNING_KEY_ALIAS and should contain the alias of your app.
3.2 The Workflow
Now that we set up our secrets, we can proceed with the actual Workflow.
Because we later want to be able to manually trigger our Workflow, we will define it as on: workflow_dispatch.
name: Build Release App Bundle on: workflow_dispatch
To decode our encoded KeyStore file, we use the base64-to-file GitHub Action by Tim Heuer.
The GitHub Action allows us to define a parameter encodedString that will refer to our GitHub secret KEYSTORE. With the fileName parameter, we set the directory and filename of our KeyStore file in the temporary directory of our Workflow.
As we discussed in the first part of this article, our build.gradle will then be able to copy and use that file as the KeyStore.
In the Administrator: Command Prompt window, type the following commands.
Press Enter key after each command:
DISM.exe /Online /Cleanup-image /Scanhealth
DISM.exe /Online /Cleanup-image /Restorehealth
Important: When you run this command, DISM uses Windows Update to provide the files that are required to fix corruptions.
To close the Administrator: Command prompt window, type Exit, and then press Enter.
Restart your computer.
So this is the current branches for this tutorial repositort just as a hypothetical example :
— Branches (NB!! -> Only 1 example branch | develop | also the main branch in this example)
develop
—
Step 1 :
Create a new branch for a new feature
git checkout -b new-branch-name-goes-here
Step 2 :
When your new branch is ready to submit code back into the system. First step you need to publish the branch to github. Assuming you haven’t already done it.
git push --set-upstream origin new-branch-name-goes-here
Step 3 :
Now that your branch is published you can add and commit your changes to
new-branch-name-goes-here
git status git add -A git commit -m "Your new message to describe what you have done goes inside these inverted commas" // Ensure your branch is up to date with your latest changes by running git status again git status // If your branch say up to date then you are good. Else you have done something wrong and need to try again.
Step 4 :
You can switch back to your main branch which you will then merge the new branch you were working on back into your main branch. In this case our main branch is develop
git checkout develop git merge new-branch-name-goes-here
Step 5 :
After you run “git merge new-branch-name-goes-here” you gshould get notified of all the conflicts if there are any.
Resolve the conflicts in your IDE (Integrated Development Environment) and then push your now updated main branch (develop) back into itself.
git push origin develop